XQuery and XPath Data Model 3.1

2.1.1 Types adopted from XML Schema

The data model adopts the following types:

• The 19 types defined in Section 3.2 Primitive datatypes^XS2 of [Schema Part 2].

• Three built-in list types: xs:NMTOKENS, xs:IDREFS, and xs:ENTITIES.

  The following types which were originally defined in [XQuery 1.0 and XPath 2.0 Data Model (XDM)] and were subsequently adopted by [Schema 1.1 Part 2]: xs:anyAtomicType, xs:dayTimeDuration, xs:yearMonthDuration.

• In the case of a processor that supports [Schema 1.1 Part 2], the data model also includes: the new union type xs:error (a type with no instances) and the new derived type xs:dateTimeStamp.

• The following types, although they use the xs: namespace, are defined here in the data model and not in XML Schema: xs:untypedAtomic , and xs:numeric, a union type whose members are xs:double, xs:float and xs:decimal.

2.7.1 Representation of Types

The data model uses expanded-QNames to represent the names of schema types, which include the built-in types defined by [Schema Part 2], five additional types defined by this specification, and may include other user- or implementation-defined types.

For XML Schema types, the namespace name of the expanded-QName is the {target namespace} property of the type definition, and its local name is the {name} property of the type definition.

The data model relies on the fact that an expanded-QName uniquely identifies every named type. Although it is possible for different schemas to define different types with the same expanded-QName, at most one of them can be used in any given validation episode. The data model cannot support environments where different types with the same expanded-QName are available.

The scope over which the names of anonymous types must be meaningful and distinct is depends on the processing context. It is the responsibility of the host language to define the size and scope of the processing context.

2.7.2 Predefined Types

In addition to the 19 types defined in Section 3.2 Primitive datatypes^XS2 of [Schema Part 2], the data model defines five additional types: xs:anyAtomicType, xs:untyped, xs:untypedAtomic, xs:dayTimeDuration, and xs:yearMonthDuration. These types are defined in the XML Schema namespace with permission of the XML Schema Working Group; in implementations that support [Schema 1.1 Part 2], the XSD 1.1 definitions of xs:anyAtomicType, xs:dayTimeDuration, and xs:yearMonthDuration supersede the definitions in this specification.

xs:untyped

The datatype xs:untyped denotes the dynamic type of an element node that has not been validated, or has been validated in skip mode. The properties of xs:untyped are the same as the properties of xs:anyType except for the base type and name. The base type of xs:untyped is xs:anyType. No predefined types are derived from xs:untyped and no such derivations are allowed.

xs:untypedAtomic

The datatype xs:untypedAtomic denotes untyped atomic data, such as text that has not been assigned a more specific type. An attribute that has been validated in skip mode is represented in the Data Model by an attribute node with the type xs:untypedAtomic. No predefined types are derived from xs:untypedAtomic and no such derivations are allowed.

xs:anyAtomicType

The datatype xs:anyAtomicType is an atomic type that includes all atomic values (and no values that are not atomic). Its base type is xs:anySimpleType from which all simple types, including atomic, list, and union types are derived. All primitive atomic types, such as xs:decimal and xs:string, have xs:anyAtomicType as their base type.

No type may be derived from xs:anyAtomicType by restriction, union, or list.

xs:dayTimeDuration

The type xs:dayTimeDuration is derived from xs:duration by restricting its lexical representation to contain only the days, hours, minutes and seconds components. The value space of xs:dayTimeDuration is the set of fractional second values. The components of xs:dayTimeDuration correspond to the day, hour, minute and second components defined in Section 5.5.3.2 of [ISO 8601]. An xs:dayTimeDuration is derived from xs:duration as follows:

<xs:simpleType name='dayTimeDuration'>
  <xs:restriction base='xs:duration'>
    <xs:pattern value="[^YM]*[DT].*"/>
  </xs:restriction>
</xs:simpleType>

xs:yearMonthDuration

The type xs:yearMonthDuration is derived from xs:duration by restricting its lexical representation to contain only the year and month components. The value space of xs:yearMonthDuration is the set of xs:integer month values. The year and month components of xs:yearMonthDuration correspond to the Gregorian year and month components defined in section 5.5.3.2 of [ISO 8601], respectively.

The type xs:yearMonthDuration is derived from xs:duration as follows:

<xs:simpleType name='yearMonthDuration'>
  <xs:restriction base='xs:duration'>
    <xs:pattern value="[^DT]*"/>
  </xs:restriction>
</xs:simpleType>

A schema for xs:dayTimeDuration and xs:yearMonthDuration is provided in C Schema for the Extended XS Namespace.

2.7.3 XML and XSD Versions

Some of the types defined in XML Schema have differing definitions in XSD 1.0 and XSD 1.1; furthermore, some types are defined by reference to other specifications including XML and XML Namespaces, and these too may vary from one version of the specification to the next.

As a general policy, implementations of data types should support the latest definitive version of any referenced specification, even if that is published after the date of this specification.

This means, for example, that the xs:string data type should (at the time of writing) support the set of characters defined by the Char production in XML 1.1 Second Edition. Similarly, the xs:anyURI data type should support the definition used in XSD 1.1 (which allows any sequence of characters), and the xs:NCName data type should support the definition based on the syntax of a name as defined in both XML 1.1 Second Edition and XML 1.0 Fifth Edition (which are the same).

In practice interoperability problems can arise both because specifications are not always in synchronization with each other (for example, XSD 1.0 contains referenced to dated versions of XML 1.0 other than the latest version), and also because implementations may use third-party components (such as XML parsers, serializers, and schema validators) that were built against different versions of the base specifications. For these reasons, use of the latest version of referenced specifications is generally recommended but not required. It is implementation-dependent how a processor handles any such conflicts.

[Definition: A string is a sequence of zero or more characters, or equivalently, a value in the value space of the xs:string data type. ]

[Definition: A character is an instance of the Char production in [XML] . ]

[Definition: A codepoint is a non-negative integer assigned to a character by the Unicode consortium, or reserved for future assignment to a character.]

2.7.4 Type System

The diagrams below show how nodes, functions, primitive simple types, and user defined types fit together into a type system. This type system comprises two distinct subsystems that both include the primitive simple types. In the diagrams, connecting lines represent relationships between derived types and the types from which they are derived; the arrowheads point toward the type from which they are derived. The dashed line represents relationships not present in this diagram, but that appear in one of the other diagrams. Dotted lines represent additional relationships that follow an evident pattern. The information that appears in each diagram is recapitulated in tabular form.

The xs:IDREFS, xs:NMTOKENS, xs:ENTITIES types, and xs:numeric and both the user-defined list types and user-defined union types are special types in that these types are lists or unions rather than types derived by extension or restriction.

The first diagram and its corresponding table illustrate the relationship of various item types. Item types in the data model form a directed graph, rather than a hierarchy or lattice: in the relationship defined by the derived-from(A, B) function, some types are derived from more than one other type. Examples include functions (function(xs:string) as xs:int is substitutable for function(xs:NCName) as xs:int and also for function(xs:string) as xs:decimal), and union types (A is substitutable for union(A, B) and also for union(A, C). In XDM, item types include node types, function types, and built-in atomic types. The diagram, which shows only hierarchic relationships, is therefore a simplification of the full model.

In the table, each type whose name is indented is derived from the type whose name appears nearest above it with one less level of indentation.

The next diagram and table illustrate the "any type" type subsystem, in which all types are derived from distinguished type xs:anyType.

In the table, each type whose name is indented is derived from the type whose name appears nearest above it with one less level of indentation.

The final diagram and table show all of the atomic types, including the primitive simple types and the built-in types derived from the primitive simple types. This includes all the built-in datatypes defined in [Schema Part 2].

In the table, each type whose name is indented is derived from the type whose name appears nearest above it with one less level of indentation.

2.7.5 Atomic Values

An atomic value can be constructed from a lexical representation. Given a string and an atomic type, the atomic value is constructed in such a way as to be consistent with schema validation. If the string does not represent a valid value of the type, an error is raised. When xs:untypedAtomic is specified as the type, no validation takes place. The details of the construction are described in Section 18 Constructor functions ^FO31 and the related Section 19 Casting ^FO31 section of [XQuery and XPath Functions and Operators 3.1].

2.7.6 String Values

A string value can be constructed from an atomic value. Such a value is constructed by converting the atomic value to its string representation as described in Section 19 Casting ^FO31 . Using the canonical lexical representation for atomic values is not always compatible with XPath 1.0. These and other backwards incompatibilities are described in [TITLE OF XP31 SPEC, TITLE OF id-backwards-compatibility SECTION]^XP31 .

2.7.7 Negative Zero

The xs:float and xs:double data types in the data model have the same value space as in XML Schema 1.1 ([Schema 1.1 Part 2]). Specifically they include both negative and positive zero, and in this respect they differ from XML Schema 1.0.

To accommodate this difference, when converting from an xs:string to an xs:float or xs:double, it is implementation-defined whether the lexical value “-0” (and similar forms such as “-0.0”) convert to negative zero or to positive zero in the value space.

2.8.1 Functions

[Definition: A function is an item that can be called. ] Functions cannot be compared for identity, equality, or otherwise, and have no serialization.

A function has the following properties:

• name (xs:QName): An expanded QName, possibly absent.

• parameter names (xs:QName*): A list of distinct names, one for each of the function's parameters.

• signature (a FunctionTest of the form Annotation* TypedFunctionTest): The TypedFunctionTest^XP31 has one SequenceType^XP31 for each parameter, and one SequenceType for the function's result. [Definition: A function signature represents the type of a function.] The presence of annotations is language dependent; functions defined in languages, such as XPath, that have no mechanism for defining annotations will create functions in the data model with zero annotations.

• implementation This enables the function, when it's called, to map instances of its parameter types into an instance of its result type. The implementation is either:

  • a host language expression, which is always associated with a static context, or

  • an implementation-dependent function implementation, which is optionally associated with both a static and a dynamic context.

• nonlocal variable bindings (a mapping from xs:QName to item()*): This provides a value for each of the function's free variables (i.e., variables referenced by the function's implementation, other than locals and parameters).

[Definition: A function's arity is the number of its parameters. ] The number of names in a function's parameter names, and the number of parameter types in its signature, must equal the function's arity.

The space of all possible function signatures forms a hierarchy of function types. All function types are a subtype of function(*), which is itself a subtype of item(). Subtypes of function(*) are partitioned into discrete types, each representing functions that accept a particular number of arguments. Function types which have the same arity can be subtypes of each other based on their argument and return types. This subtype relationship is defined in Section 2.5.6 SequenceType Subtype Relationships ^XP31 . For example:

• function(item()) as item() is a subtype of function(*)

• function(item()) as xs:integer is a subtype of function(item()) as item()

• function(item()) as item() is a subtype of function(xs:string) as item()

2.8.2 Map Items

[Definition: A map item is a value that represents a map (sometimes called a hash or an associative array).] A map is logically a collection of key/value pairs. Each key in the map is unique (there is no other key to which it is equal) and has associated with it a value that is a single item or sequence of items. There is no uniqueness constraint on values. The semantics of equality are described in Section 17.1.1 op:same-key ^FO31.

There is a single accessor associated with maps, it is defined in the following section.

2.8.3 Array Items

[Definition: An array item is a value that represents an array.] An array is an ordered list of values; these values are called the members of the array. Unlike sequences, a member of an array can be any value (including a sequence or an array). The number of members in an array is called its size, and they are referenced by their position, in the range 1 to the size of the array.

The accessors associated with arrays are defined in the following sections.

3.3.1 Mapping PSVI Additions to Node Properties

A PSVI element or attribute information item may have a [validity] property. The [validity] property may be " valid ", " invalid ", or " notKnown " and reflects the outcome of schema-validity assessment. In the data model, precise schema type information is exposed for Element and Attribute Nodes that are " valid ". Nodes that are not " valid " are treated as if they were simply well-formed XML and only very general schema type information is associated with them.

<offset xsi:type="xs:integer">0030</offset>

3.3.2 Dates and Times

The date and time types require special attention. This section applies to implementations that store the typed value of xs:dateTime, xs:date, xs:time, xs:gYearMonth, xs:gYear, xs:gMonthDay, xs:gMonth, xs:gDay, and types that are derived from them. These are known collectively as the date/time types in this specification.

The values of the date/time types are represented in the data model using seven components:

year

An xs:integer.

month

An xs:integer between 1 and 12, inclusive.

day

An xs:integer between 1 and 31, inclusive, possibly restricted further depending on the values of month and year.

hour

An xs:integer between 0 and 23, inclusive.

minute

An xs:integer between 0 and 59, inclusive.

second

An xs:decimal greater than or equal to zero and less than 60. Leap seconds are not supported.

timezone

An xs:dayTimeDuration between -PT14H00M and PT14H00M, inclusive. All timezone values must be an integral number of minutes.

Components that are intrinsic to the datatype (for example, day, month, and year in a xs:date) are required; components that can never be part of a datatype (for example, years in a xs:time) must be missing. Missing components are represented by the empty sequence. When a component is present, it contains the “local value” that has not been normalized in any way. The timezone component is optional for all the date/time datatypes.

Thus, the lexical xs:dateTime representation “2003-01-02T11:30:00-05:00” is stored as “{2003, 1, 2, 11, 30, 0.0, -PT05H00M}”. The value of the lexical representation “2003-01-16T16:30:00” is stored as “{2003, 1, 16, 16, 30, 0, ()}” because it has no timezone. The value of the lexical xs:gDay representation “---30+10:30” is stored as “{(), (), 30, (), (), (), PT10H30M}”.

The lexical form “24:00:00” is normalized in the component model. As a xs:time, it is stored as “{(), (), (), 0, 0, 0.0, ()}” and the xs:dateTime representation “1999-12-31T24:00:00” is stored as “{2000, 1, 1, 0, 0, 0.0, ()}”.

3.3.3 QNames and NOTATIONS

The QName and NOTATION data types require special attention. The following sections apply to xs:QName, xs:NOTATION, and types derived from them. These types are referred to collectively as “qualified names”.

As defined in XML Schema, the lexical space for qualified names includes a local name and an optional namespace prefix. The value space for qualified names contains a local name and an optional namespace URI. Therefore, it is not possible to derive a lexical value from the typed value, or vice versa, without access to some context that defines the namespace bindings.

When qualified names exist as values of nodes in a well-formed document, it is always possible to determine such a namespace context. However, the data model also allows qualified names to exist as freestanding atomic values, or as the name or value of a parentless attribute node, and in these cases no namespace context is available.

In this Data Model, therefore, the value space for qualified names contains a local-name, an optional namespace URI, and an optional prefix. The prefix is used only when producing a lexical representation of the value, that is, when casting the value to a string. The prefix plays no part in other operations involving qualified names: in particular, two qualified names are equal if their local names and namespace URIs match, regardless whether they have the same prefix.

The following consistency constraints apply:

• If the namespace URI of a qualified name is absent, then the prefix must also be absent.

• For every element node whose name has a prefix, the prefix must be one that has a binding to the namespace URI of the element name in the namespaces property of the element.

• For every element node whose name has no prefix, the element must have a a binding for the empty prefix to the namespace URI of the element name, or must have no binding for the empty prefix in the case where the name of the element has no namespace URI.

• For every attribute node whose name has a prefix, the attribute node must either be parentless, or the prefix must be one that has a binding to the namespace URI of the attribute name in the namespaces property of the parent element.

• For every qualified name that contains a prefix and that is included in the typed value of an element node, or of an attribute node that has an element node as its parent, the prefix must be one that is bound to the namespace URI of the qualified name in the namespaces property of that element.

• For every qualified name that contains a namespace URI and no prefix, and that is included in the typed value of an element node, or of an attribute node that has an element node as its parent, that element node must have a binding for the empty prefix to that namespace URI in its namespace property.

• For every qualified name that contains neither a namespace URI nor a prefix, and that is included in the typed value of an element node, or of an attribute node that has an element node as its parent, that node must not have a binding for the empty prefix.

• No qualified name that contains a prefix may be included in the typed value of an attribute node that has no parent.

6.1.1 Overview

Document Nodes encapsulate XML documents. Documents have the following properties:

• base-uri, possibly empty.

• children, possibly empty.

• unparsed-entities, possibly empty.

• document-uri, possibly empty.

• string-value

• typed-value

Document Nodes must satisfy the following constraints.

1. The children must consist exclusively of Element, Processing Instruction, Comment, and Text Nodes if it is not empty. Attribute, Namespace, and Document Nodes can never appear as children

2. If a node N is among the children of a Document Node D, then the parent of N must be D.

3. If a node N has a parent Document Node D, then N must be among the children of D.

4. The string-value property of a Document Node must be the concatenation of the string-values of all its Text Node descendants in document order or, if the document has no such descendants, the zero-length string.

In the [Infoset], a document information item must have at least one child, its children must consist exclusively of element information items, processing instruction information items and comment information items, and exactly one of the children must be an element information item. This data model is more permissive: a Document Node may be empty, it may have more than one Element Node as a child, and it also permits Text Nodes as children.

Implementations that support DTD processing and access to the unparsed entity accessors use the unparsed-entities property to associate information about an unordered collection of unparsed entities with a Document Node. This property is accessed indirectly through the dm:unparsed-entity-system-id and dm:unparsed-entity-public-id functions. There is at most one unparsed entity associated with any given name. Conforming XML documents may include more than one unparsed entity declaration for the same name, but XML mandates that only the first such declaration is significant.

6.1.2 Accessors

dm:attributes

Returns the empty sequence

dm:base-uri

Returns the value of the base-uri property.

dm:children

Returns the value of the children property.

dm:document-uri

Returns the absolute URI of the resource from which the Document Node was constructed, or the empty sequence if no such absolute URI is available.

dm:is-id

Returns the empty sequence.

dm:is-idrefs

Returns the empty sequence.

dm:namespace-nodes

Returns the empty sequence

dm:nilled

Returns the empty sequence

dm:node-kind

Returns “document”.

dm:node-name

Returns the empty sequence.

dm:parent

Returns the empty sequence

dm:string-value

Returns the value of the string-value property.

dm:type-name

Returns the empty sequence.

dm:typed-value

Returns the value of the typed-value property.

dm:unparsed-entity-public-id

Returns the public identifier of the specified unparsed entity or the empty sequence if no such entity exists.

dm:unparsed-entity-system-id

Returns the system identifier of the specified unparsed entity or the empty sequence if no such entity exists.

6.1.3 Construction from an Infoset

The document information item is required. A Document Node is constructed for each document information item.

The following infoset properties are required: [children] and [base URI].

The following infoset properties are optional: [unparsed entities].

Document Node properties are derived from the infoset as follows:

base-uri

The value of the [base URI] property, if available. Note that the base URI property, if available, is always an absolute URI (if an absolute URI can be computed) though it may contain Unicode characters that are not allowed in URIs. These characters, if they occur, are present in the base-uri property and will have to be encoded and escaped by the application to obtain a URI suitable for retrieval, if retrieval is required.

In practice a [base URI] is not always known. In this case the value of the base-uri property of the document node will be the empty sequence. This is not intrinsically an error, though it may cause some operations that depend on the base URI to fail.

children

The sequence of nodes constructed from the information items found in the [children] property.

For each element, processing instruction, and comment found in the [children] property, a corresponding Element, Processing Instruction, or Comment Node is constructed and that sequence of nodes is used as the value of the children property.

If present among the [children], the document type declaration information item is ignored.

unparsed-entities

If the [unparsed entities] property is present and is not the empty set, the values of the unparsed entity information items must be used to support the dm:unparsed-entity-system-id and dm:unparsed-entity-public-id accessors.

The internal structure of the values of the unparsed-entities property is implementation defined.

string-value

The concatenation of the string-values of all its Text Node descendants in document order. If the document has no such descendants, the zero-length string.

typed-value

The dm:string-value of the node as an xs:untypedAtomic value.

document-uri

The document-uri property holds the absolute URI for the resource from which the document node was constructed, if one is available and can be made absolute. For example, if a collection of documents is returned by the fn:collection function, the document-uri property may serve to distinguish between them even though each has the same base-uri property.

If the document-uri is not the empty sequence, then the following constraint must hold: the node returned by evaluating fn:doc() with the document-uri as its argument must return the document node that provided the value of the document-uri property.

In other words, for any Document Node $arg, either fn:document-uri($arg) must return the empty sequence or fn:doc(fn:document-uri($arg)) must return $arg.

6.1.4 Construction from a PSVI

Construction from a PSVI is identical to construction from the Infoset.

6.1.5 Infoset Mapping

A Document Node maps to a document information item. The mapping fails and produces no value if the Document Node contains Text Node children that do not consist entirely of white space or if the Document Node contains more than one Element Node child.

The following properties are specified by this mapping:

[children]

A list of information items obtained by processing each of the dm:children in order and mapping each to the appropriate information item(s).

[document element]

The element information item that is among the [children].

[unparsed entities]

An unordered set of unparsed entity information items constructed from the unparsed-entities.

Each unparsed entity maps to an unparsed entity information item. The following properties are specified by this mapping:

[name]

The name of the entity.

[system identifier]

The system identifier of the entity.

[public identifier]

The public identifier of the entity.

[declaration base URI]

Implementation defined. In many cases, the document-uri is the correct answer and implementations must use this value if they have no better information. Implementations that keep track of the original [declaration base URI] for entities should use that value.

The following properties of the unparsed entity information item have no value: [notation name], [notation].

The following properties of the document information item have no value: [notations] [character encoding scheme] [standalone] [version] [all declarations processed].

6.2.1 Overview

Element Nodes encapsulate XML elements. Elements have the following properties:

• base-uri, possibly empty.

• node-name

• parent, possibly empty

• schema-type

• children, possibly empty

• attributes, possibly empty

• namespaces

• nilled

• string-value

• typed-value

• is-id

• is-idrefs

Element Nodes must satisfy the following constraints.

1. The children must consist exclusively of Element, Processing Instruction, Comment, and Text Nodes if it is not empty. Attribute, Namespace, and Document Nodes can never appear as children

2. The Attribute Nodes of an element must have distinct xs:QNames.

3. If a node N is among the children of an element E, then the parent of N must be E.

4. Exclusive of Attribute and Namespace Nodes, if a node N has a parent element E, then N must be among the children of E. (Attribute and Namespace Nodes have a parent, but they do not appear among the children of their parent.)

   The data model permits Element Nodes without parents (to represent partial results during expression processing, for example). Such Element Nodes must not appear among the children of any other node.

   An element may not be its own child or its own parent.

5. If an Attribute Node A is among the attributes of an element E, then the parent of A must be E.

6. If an Attribute Node A has a parent element E, then A must be among the attributes of E.

   The data model permits Attribute Nodes without parents. Such Attribute Nodes must not appear among the attributes of any Element Node.

7. If a Namespace Node N is among the namespaces of an element E, then the parent of N must be E.

8. If a Namespace Node N has a parent element E, then N must be among the namespaces of E.

   The data model permits Namespace Nodes without parents. Such Namespace Nodes must not appear among the namespaces of any Element Node. This constraint is irrelevant for implementations that do not support Namespace Nodes.

9. If the dm:type-name of an Element Node is xs:untyped, then the dm:type-name of all its descendant elements must also be xs:untyped and the dm:type-name of all its Attribute Nodes must be xs:untypedAtomic.

10. If the dm:type-name of an Element Node is xs:untyped, then the nilled property must be false.

11. If the nilled property is true, then the children property must not contain Element Nodes or Text Nodes.

12. For every expanded QName that appears in the dm:node-name of the element, the dm:node-name of any Attribute Node among the attributes of the element, or in any value of type xs:QName or xs:NOTATION (or any type derived from those types) that appears in the typed-value of the element or the typed-value of any of its attributes, if the expanded QName has a non-empty URI, then there must be a prefix binding for this URI among the namespaces of this Element Node.

    If any of the expanded QNames has an empty URI, then there must not be any binding among the namespaces of this Element Node which binds the empty prefix to a URI.

13. Every element must include a Namespace Node and/or namespace binding for the prefix xml bound to the URI http://www.w3.org/XML/1998/namespace and there must be no other prefix bound to that URI.

14. The string-value property of an Element Node must be the concatenation of the string-values of all its Text Node descendants in document order or, if the element has no such descendants, the zero-length string.

6.2.2 Accessors

dm:attributes

Returns the value of the attributes property. The order of Attribute Nodes is stable but implementation dependent.

dm:base-uri

Returns the value of the base-uri property.

dm:children

Returns the value of the children property.

dm:document-uri

Returns the empty sequence.

dm:is-id

Returns the value of the is-id property.

dm:is-idrefs

Returns the value of the is-idrefs property.

dm:namespace-nodes

Returns the value of the namespaces property as a sequence of Namespace Nodes. The order of Namespace Nodes is stable but implementation dependent.

dm:nilled

Returns the value of the nilled property.

dm:node-kind

Returns “element”.

dm:node-name

Returns the value of the node-name property.

dm:parent

Returns the value of the parent property.

dm:string-value

Returns the value of the string-value property.

dm:type-name

Returns the value of the schema-type property.

dm:typed-value

Returns the value of the typed-value property.

dm:unparsed-entity-public-id

Returns the empty sequence.

dm:unparsed-entity-system-id

Returns the empty sequence.

6.2.3 Construction from an Infoset

The element information items are required. An Element Node is constructed for each element information item.

The following infoset properties are required: [namespace name], [local name], [children], [attributes], [in-scope namespaces], [base URI], and [parent].

Element Node properties are derived from the infoset as follows:

base-uri

The value of the [base URI] property, if available. Note that the base URI property, if available, is always an absolute URI (if an absolute URI can be computed) though it may contain Unicode characters that are not allowed in URIs. These characters, if they occur, are present in the base-uri property and will have to be encoded and escaped by the application to obtain a URI suitable for retrieval, if retrieval is required.

In practice a [base URI] is not always known. In this case the value of the base-uri property of the document node will be the empty sequence. This is not intrinsically an error, though it may cause some operations that depend on the base URI to fail.

node-name

An xs:QName constructed from the [prefix], [local name], and [namespace name] properties.

parent

The node that corresponds to the value of the [parent] property or the empty sequence if there is no parent.

schema-type

All Element Nodes constructed from an infoset have the type xs:untyped.

children

The sequence of nodes constructed from the information items found in the [children] property.

For each element, processing instruction, comment, and maximal sequence of adjacent character information items found in the [children] property, a corresponding Element, Processing Instruction, Comment, or Text Node is constructed and that sequence of nodes is used as the value of the children property.

Because the data model requires that all general entities be expanded, there will never be unexpanded entity reference information item children.

attributes

A set of Attribute Nodes constructed from the attribute information items appearing in the [attributes] property. This includes all of the "special" attributes (xml:lang, xml:space, xsi:type, etc.) but does not include namespace declarations (because they are not attributes).

Default and fixed attributes provided by the DTD are added to the [attributes] and are therefore included in the data model attributes of an element.

namespaces

A set of Namespace Nodes constructed from the namespace information items appearing in the [in-scope namespaces] property. Implementations that do not support Namespace Nodes may simply preserve the relevant bindings in this property.

Implementations may ignore namespace information items for namespaces which are not known to be used. A namespace is known to be used if:

• It appears in the expanded QName of the node-name of the element.

• It appears in the expanded QName of the node-name of any of the element's attributes.

Note: applications may rely on namespaces that are not known to be used, for example when QNames are used in content and that content does not have a type of xs:QName Such applications may have difficulty processing data models where some namespaces have been ignored.

nilled

All Element Nodes constructed from an infoset have a nilled property of " false ".

string-value

The string-value is constructed from the character information item [children] of the element and all its descendants. The precise rules for selecting significant character information items and constructing characters from them is described in 6.7.3 Construction from an Infoset of 6.7 Text Nodes.

This process is equivalent to concatenating the dm:string-values of all of the Text Node descendants of the resulting Element Node.

If the element has no such descendants, the string-value is the empty string.

typed-value

The string-value as an xs:untypedAtomic.

is-id

All Element Nodes constructed from an infoset have a is-id property of " false ".

is-idrefs

All Element Nodes constructed from an infoset have a is-idrefs property of " false ".

6.2.4 Construction from a PSVI

The following Element Node properties are affected by PSVI properties.

schema-type

The schema-type is determined as described in 3.3.1.1 Element and Attribute Node Types.

children

The sequence of nodes constructed from the information items found in the [children] property.

For each element, processing instruction, comment, and maximal sequence of adjacent character information items found in the [children] property, a corresponding Element, Processing Instruction, Comment, or Text Node is constructed and that sequence of nodes is used as the value of the children property.

For elements with schema simple types, or complex types with simple content, if the [schema normalized value] PSVI property exists, the processor may use a sequence of nodes containing the Processing Instruction and Comment Nodes corresponding to the processing instruction and comment information items found in the [children] property, plus an optional single Text Node whose string value is the [schema normalized value] for the children property. If the [schema normalized value] is the empty string, the Text Node must not be present, otherwise it must be present.

The relative order of Processing Instruction and Comment Nodes must be preserved, but the position of the Text Node, if it is present, among them is implementation defined.

The effect of the above rules is that where a fixed or default value for an element is defined in the schema, and the element takes this default value, a text node will be created to contain the value, even though there are no character information items representing the value in the PSVI. The position of this text node relative to any comment or processing instruction children is implementation-dependent.

[Schema Part 1] also permits an element with mixed content to take a default or fixed value (which will always be a simple value), but it is unclear how such a defaulted value is represented in the PSVI. Implementations therefore may represent such a default value by creating a text node, but are not required to do so.

Note:

Section 3.3.1 in [Schema 1.1 Part 1] clarifies the PSVI contributions of element default or fixed values in mixed content: additional character information items are not added to the PSVI.

Because the data model requires that all general entities be expanded, there will never be unexpanded entity reference information item children.

attributes

A set of Attribute Nodes constructed from the attribute information items appearing in the [attributes] property. This includes all of the "special" attributes (xml:lang, xml:space, xsi:type, etc.) but does not include namespace declarations (because they are not attributes).

Default and fixed attributes provided by XML Schema processing are added to the [attributes] and are therefore included in the data model attributes of an element.

namespaces

A set of Namespace Nodes constructed from the namespace information items appearing in the [in-scope namespaces] property. Implementations that do not support Namespace Nodes may simply preserve the relevant bindings in this property.

Implementations may ignore namespace information items for namespaces which are not known to be used. A namespace is known to be used if:

• It appears in the expanded QName of the node-name of the element.

• It appears in the expanded QName of the node-name of any of the element's attributes.

• It appears in the expanded QName of any values of type xs:QName that appear among the element's children or the typed values of its attributes.

Note: applications may rely on namespaces that are not known to be used, for example when QNames are used in content and that content does not have a type of xs:QName Such applications may have difficulty processing data models where some namespaces have been ignored.

nilled

If the [validity] property exists on an information item and is " valid " then if the [nil] property exists and is true, then the nilled property is " true ". In all other cases, including all cases where schema validity assessment was not attempted or did not succeed, the nilled property is " false ".

string-value

The string-value is calculated as follows:

• If the element is empty: its string value is the zero length string.

• If the element has a type of xs:untyped, a complex type with element-only content, or a complex type with mixed content: its string-value is the concatenation of the string-values of all its Text Node descendants in document order.

• If the element has a simple type or a complex type with simple content: its string-value is the [schema normalized value] of the node.

If an implementation stores only the typed value of an element, it may use any valid lexical representation of the typed value for the string-value property.

typed-value

The typed-value is calculated as follows:

• If the element is of type xs:untyped, its typed-value is its dm:string-value as an xs:untypedAtomic.

• If the element has a complex type with empty content, its typed-value is the empty sequence.

• If the element has a simple type or a complex type with simple content: its typed value is computed as described in 3.3.1.2 Typed Value Determination. The result is a sequence of zero or more atomic values. The relationship between the type-name, typed-value, and string-value of an element node is consistent with XML Schema validation.

  Note that in the case of dates and times, the timezone is preserved as described in 3.3.2 Dates and Times, and in the case of xs:QNames and xs:NOTATIONs, the prefix is preserved as described in 3.3.3 QNames and NOTATIONS.

• If the element has a complex type with mixed content (including xs:anyType), its typed-value is its dm:string-value as an xs:untypedAtomic.

• Otherwise, the element must be a complex type with element-only content. The typed-value of such an element is absent. Attempting to access this property with the dm:typed-value accessor always raises an error.

is-id

If the element has a complex type with element-only content, the is-id property is false. Otherwise, if the typed-value of the element consists of exactly one atomic value and that value is of type xs:ID, or a type derived from xs:ID, the is-id property is true, otherwise it is false.

Note:

This means that in the case of a type constructed by list from xs:ID, the ID is recognized provided that the list is of length one. A type constructed as a union involving xs:ID is recognized provided the actual value is of type xs:ID.

Note:

The element that is marked with the is-id property, and which will therefore be retrieved by the fn:id function, is the node whose typed value contains the xs:ID value. This node is a child of the element node that, according to XML Schema, is uniquely identified by this ID.

is-idrefs

If the element has a complex type with element-only content, the is-idrefs property is false. Otherwise, if any of the atomic values in the typed-value of the element is of type xs:IDREF or xs:IDREFS, or a type derived from one of those types, the is-idrefs property is true, otherwise it is false.

All other properties have values that are consistent with construction from an infoset.

6.2.5 Infoset Mapping

An Element Node maps to an element information item.

The following properties are specified by this mapping:

[namespace name]

The namespace name of the value of dm:node-name.

[local name]

The local part of the value of dm:node-name.

[prefix]

The prefix associated with the value of dm:node-name.

[children]

A list of information items obtained by processing each of the dm:children in order and mapping each to the appropriate information item(s).

[attributes]

An unordered set of information items obtained by processing each of the dm:attributes and mapping each to the appropriate information item(s).

[in-scope namespaces]

An unordered set of namespace information items constructed from the namespaces.

Each in-scope namespace maps to a namespace information item. The following properties are specified by this mapping:

[prefix]

The prefix associated with the namespace.

[namespace name]

The URI associated with the namespace.

[base URI]

The value of dm:base-uri.

[parent]

• If this node is the root of the infoset mapping operation, unknown.

• If this node has a parent, the information item that corresponds to the node returned by dm:parent.

• Otherwise no value.

The following property has no value: [namespace attributes].

6.3.1 Overview

Attribute Nodes represent XML attributes. Attributes have the following properties:

• node-name

• parent, possibly empty

• schema-type

• string-value

• typed-value

• is-id

• is-idrefs

Attribute Nodes must satisfy the following constraints.

1. If an Attribute Node A is among the attributes of an element E, then the parent of A must be E.

2. If a Attribute Node A has a parent element E, then A must be among the attributes of E.

   The data model permits Attribute Nodes without parents (to represent partial results during expression processing, for example). Such attributes must not appear among the attributes of any Element Node.

3. In the node-name of an attribute node, if a namespace URI is present then a prefix must also be present.

For convenience, the Element Node that owns this attribute is called its "parent" even though an Attribute Node is not a "child" of its parent element.

6.3.2 Accessors

dm:attributes

Returns the empty sequence.

dm:base-uri

If the attribute has a parent, returns the value of the dm:base-uri of its parent; otherwise it returns the empty sequence.

dm:children

Returns the empty sequence.

dm:document-uri

Returns the empty sequence.

dm:is-id

Returns the value of the is-id property.

dm:is-idrefs

Returns the value of the is-idrefs property.

dm:namespace-nodes

Returns the empty sequence.

dm:nilled

Returns the empty sequence.

dm:node-kind

Returns “attribute”.

dm:node-name

Returns the value of the node-name property.

dm:parent

Returns the value of the parent property.

dm:string-value

Returns the value of the string-value property.

dm:type-name

Returns the value of the schema-type property.

dm:typed-value

Returns the value of the typed-value property.

dm:unparsed-entity-public-id

Returns the empty sequence.

dm:unparsed-entity-system-id

Returns the empty sequence.

6.3.3 Construction from an Infoset

The attribute information items are required. An Attribute Node is constructed for each attribute information item.

The following infoset properties are required: [namespace name], [local name], [normalized value], [attribute type], and [owner element].

Attribute Node properties are derived from the infoset as follows:

node-name

An xs:QName constructed from the [prefix], [local name], and [namespace name] properties.

parent

The Element Node that corresponds to the value of the [owner element] property or the empty sequence if there is no owner.

schema-type

The value xs:untypedAtomic.

string-value

The [normalized value] of the attribute.

typed-value

The attribute’s typed-value is its dm:string-value as an xs:untypedAtomic.

is-id

If the attribute is named xml:id and its [attribute type] property does not have the value ID, then [xml:id] processing is performed. This will assure that the value does have the type ID and that it is properly normalized. If an error is encountered during xml:id processing, an implementation may raise a dynamic error. The is-id property is always true for attributes named xml:id.

If the [attribute type] property has the value ID, true, otherwise false.

is-idrefs

If the [attribute type] property has the value IDREF or IDREFS, true, otherwise false.

6.3.4 Construction from a PSVI

The following Attribute Node properties are affected by PSVI properties.

string-value

• The [schema normalized value] PSVI property if that exists.

• Otherwise, the [normalized value] property.

If an implementation stores only the typed value of an attribute, it may use any valid lexical representation of the typed value for the string-value property.

schema-type

The schema-type is determined as described in 3.3.1.1 Element and Attribute Node Types.

typed-value

The typed-value is calculated as follows:

• If the attribute is of type xs:untypedAtomic: its typed-value is its dm:string-value as an xs:untypedAtomic.

• Otherwise, a sequence of zero or more atomic values as described in 3.3.1.2 Typed Value Determination. The relationship between the type-name, typed-value, and string-value of an attribute node is consistent with XML Schema validation.

is-id

If the attribute is named xml:id and its [attribute type] property does not have the value xs:ID or a type derived from xs:ID, then [xml:id] processing is performed. This will assure that the value does have the type xs:ID and that it is properly normalized. If an error is encountered during xml:id processing, an implementation may raise a dynamic error. The is-id property is always true for attributes named xml:id.

Otherwise, if the typed-value of the attribute consists of exactly one atomic value and that value is of type xs:ID, or a type derived from xs:ID, the is-id property is true, otherwise it is false.

Note:

This means that in the case of a type constructed by list from xs:ID, the ID is recognized provided that the list is of length one. A type constructed as a union involving xs:ID is recognized provided the actual value is of type xs:ID.

is-idrefs

If any of the atomic values in the typed-value of the attribute is of type xs:IDREF or xs:IDREFS, or a type derived from one of those types, the is-idrefs property is true, otherwise it is false.

Note:

This rule means that a node whose type is constructed by list with an item type of xs:IDREF (or a type derived from xs:IDREF) may have the is-idrefs property, whether or not the list type is named xs:IDREFS or is derived from xs:IDREFS. Because union types are allowed, it also means that an element or attribute with the is-idrefs property can contain atomic values of type xs:IDREF alongside values of other types. A node has the is-idrefs property only if the typed value contains at least one atomic value that is an instance of xs:IDREF; it is not sufficient that the type annotation permits such values.

All other properties have values that are consistent with construction from an infoset.

Note: attributes from the XML Schema instance namespace, " http://www.w3.org/2001/XMLSchema-instance ", (xsi:schemaLocation, xsi:type, etc.) appear as ordinary attributes in the data model.

6.3.5 Infoset Mapping

An Attribute Node maps to an attribute information item.

The following properties are specified by this mapping:

[namespace name]

The namespace name of the value of dm:node-name.

[local name]

The local part of the value of dm:node-name.

[prefix]

The prefix associated with the value of dm:node-name.

[normalized value]

The value of dm:string-value.

[owner element]

• If this node has a parent, the information item that corresponds to the node returned by dm:parent.

• Otherwise no value.

The following properties have no value: [specified] [attribute type] [references].

6.4.1 Overview

Each Namespace Node represents the binding of a namespace URI to a namespace prefix or to the default namespace. Implementations that do not use Namespace Nodes may represent the same information using the namespaces property of an element node. Namespaces have the following properties:

• prefix, possibly empty

• uri

• parent, possibly empty

Namespace Nodes must satisfy the following constraints.

1. If a Namespace Node N is among the namespaces of an element E, then the parent of N must be E.

2. If a Namespace Node N has a parent element E, then N must be among the namespaces of E.

3. A Namespace Node must not have the name xmlns nor the string-value http://www.w3.org/2000/xmlns/.

The data model permits Namespace Nodes without parents, see below.

In XPath 1.0, Namespace Nodes were directly accessible by applications, by means of the namespace axis. In XPath 3.1 the namespace axis is deprecated, and it is not available at all in XQuery 3.1. XPath 3.1 implementations are not required to expose the namespace axis, though they may do so if they wish to offer backwards compatibility.

The information held in namespace nodes is instead made available to applications using functions defined in [XQuery and XPath Functions and Operators 3.1]. Some properties of Namespace Nodes are not exposed by these functions: in particular, properties related to the identity of Namespace Nodes, their parentage, and their position in document order. Implementations that do not expose the namespace axis can therefore avoid the overhead of maintaining this information.

Implementations that expose the namespace axis must provide unique Namespace Nodes for each element. Each element has an associated set of Namespace Nodes, one for each distinct namespace prefix that is in scope for the element (including the xml prefix, which is implicitly declared by [Namespaces in XML] and one for the default namespace if one is in scope for the element. The element is the parent of each of these Namespace Nodes; however, a Namespace Node is not a child of its parent element. In implementations that expose the namespace axis, elements never share namespace nodes.

6.4.2 Accessors

dm:attributes

Returns the empty sequence.

dm:base-uri

Returns the empty sequence.

dm:children

Returns the empty sequence.

dm:document-uri

Returns the empty sequence.

dm:is-id

Returns the empty sequence.

dm:is-idrefs

Returns the empty sequence.

dm:namespace-nodes

Returns the empty sequence.

dm:nilled

Returns the empty sequence.

dm:node-kind

Returns “namespace”.

dm:node-name

If the prefix is not empty, returns an xs:QName with the value of the prefix property in the local-name and an empty namespace name, otherwise returns the empty sequence.

dm:parent

Returns the value of the parent property.

dm:string-value

Returns the value of the uri property.

dm:type-name

Returns the empty sequence.

dm:typed-value

Returns the value of the uri property as an xs:string.

dm:unparsed-entity-public-id

Returns the empty sequence.

dm:unparsed-entity-system-id

Returns the empty sequence.

6.4.3 Construction from an Infoset

The namespace information items are required.

The following infoset properties are required: [prefix], [namespace name].

Namespace Node properties are derived from the infoset as follows:

prefix

The [prefix] property.

uri

The [namespace name] property.

parent

The element in whose [in-scope namespaces] property the namespace information item appears, if the implementation exposes any mechanism for accessing the dm:parent accessor of Namespace Nodes.

6.4.4 Construction from a PSVI

Construction from a PSVI is identical to construction from the Infoset.

6.4.5 Infoset Mapping

A Namespace Node maps to a namespace information item.

The following properties are specified by this mapping:

[prefix]

The prefix associated with the namespace.

[namespace name]

The value of dm:string-value.

6.5.1 Overview

Processing Instruction Nodes encapsulate XML processing instructions. Processing instructions have the following properties:

• target

• content

• base-uri, possibly empty

• parent, possibly empty

Processing Instruction Nodes must satisfy the following constraints.

1. The string "?>" must not occur within the content.

2. The target must be an NCName.

6.5.2 Accessors

dm:attributes

Returns the empty sequence.

dm:base-uri

Returns the value of the base-uri property.

dm:children

Returns the empty sequence.

dm:document-uri

Returns the empty sequence.

dm:is-id

Returns the empty sequence.

dm:is-idrefs

Returns the empty sequence.

dm:namespace-nodes

Returns the empty sequence.

dm:nilled

Returns the empty sequence.

dm:node-kind

Returns “processing-instruction”.

dm:node-name

Returns an xs:QName with the value of the target property in the local-name and an empty namespace URI and empty prefix.

dm:parent

Returns the value of the parent property.

dm:string-value

Returns the value of the content property.

dm:type-name

Returns the empty sequence.

dm:typed-value

Returns the value of the content property as a xs:string.

dm:unparsed-entity-public-id

Returns the empty sequence.

dm:unparsed-entity-system-id

Returns the empty sequence.

6.5.3 Construction from an Infoset

A Processing Instruction Node is constructed for each processing instruction information item that is not ignored.

The following infoset properties are required: [target], [content], [base URI], and [parent].

Processing Instruction Node properties are derived from the infoset as follows:

target

The value of the [target] property.

content

The value of the [content] property.

base-uri

The value of the [base URI] property, if available. Note that the base URI property, if available, is always an absolute URI (if an absolute URI can be computed) though it may contain Unicode characters that are not allowed in URIs. These characters, if they occur, are present in the base-uri property and will have to be encoded and escaped by the application to obtain a URI suitable for retrieval, if retrieval is required.

In practice a [base URI] is not always known. In this case the value of the base-uri property of the document node will be the empty sequence. This is not intrinsically an error, though it may cause some operations that depend on the base URI to fail.

parent

The node corresponding to the value of the [parent] property.

There are no Processing Instruction Nodes for processing instructions that are children of a document type declaration information item.

6.5.4 Construction from a PSVI

Construction from a PSVI is identical to construction from the Infoset.

6.5.5 Infoset Mapping

An Processing Instruction Node maps to a processing instruction information item.

The following properties are specified by this mapping:

[target]

The local part of the value of dm:node-name.

[content]

The value of dm:string-value.

[base URI]

The value of dm:base-uri.

[parent]

• If this node is the root of the infoset mapping operation, unknown.

• If this node has a parent, the information item that corresponds to the node returned by dm:parent.

• Otherwise no value.

[notation]

no value.

6.6.1 Overview

Comment Nodes encapsulate XML comments. Comments have the following properties:

• content

• parent, possibly empty

Comment Nodes must satisfy the following constraints.

1. The string "--" must not occur within the content.

2. The character "-" must not occur as the last character of the content.

6.6.2 Accessors

dm:attributes

Returns the empty sequence.

dm:base-uri

If the comment has a parent, returns the value of the dm:base-uri of its parent; otherwise, returns the empty sequence.

dm:children

Returns the empty sequence.

dm:document-uri

Returns the empty sequence.

dm:is-id

Returns the empty sequence.

dm:is-idrefs

Returns the empty sequence.

dm:namespace-nodes

Returns the empty sequence.

dm:nilled

Returns the empty sequence.

dm:node-kind

Returns “comment”.

dm:node-name

Returns the empty sequence.

dm:parent

Returns the value of the parent property.

dm:string-value

Returns the value of the content property.

dm:type-name

Returns the empty sequence.

dm:typed-value

Returns the value of the content property as a xs:string.

dm:unparsed-entity-public-id

Returns the empty sequence.

dm:unparsed-entity-system-id

Returns the empty sequence.

6.6.3 Construction from an Infoset

The comment information items are optional.

A Comment Node is constructed for each comment information item.

The following infoset properties are required: [content] and [parent].

Comment Node properties are derived from the infoset as follows:

content

The value of the [content] property.

parent

The node corresponding to the value of the [parent] property.

There are no Comment Nodes for comments that are children of a document type declaration information item.

6.6.4 Construction from a PSVI

Construction from a PSVI is identical to construction from the Infoset.

6.6.5 Infoset Mapping

A Comment Node maps to a comment information item.

The following properties are specified by this mapping:

[content]

The value of the dm:string-value.

[parent]

• If this node is the root of the infoset mapping operation, unknown.

• If this node has a parent, the information item that corresponds to the node returned by dm:parent.

• Otherwise no value.

6.7.1 Overview

Text Nodes encapsulate XML character content. Text has the following properties:

• content

• parent, possibly empty.

Text Nodes must satisfy the following constraint:

1. If the parent of a text node is not empty, the Text Node must not contain the zero-length string as its content.

In addition, Document and Element Nodes impose the constraint that two consecutive Text Nodes can never occur as adjacent siblings. When a Document or Element Node is constructed, Text Nodes that would be adjacent must be combined into a single Text Node. If the resulting Text Node is empty, it must never be placed among the children of its parent, it is simply discarded.

6.7.2 Accessors

dm:attributes

Returns the empty sequence.

dm:base-uri

If the Text Node has a parent, returns the value of the dm:base-uri of its parent; otherwise, returns the empty sequence.

dm:children

Returns the empty sequence.

dm:document-uri

Returns the empty sequence.

dm:is-id

Returns the empty sequence.

dm:is-idrefs

Returns the empty sequence.

dm:namespace-nodes

Returns the empty sequence.

dm:nilled

Returns the empty sequence.

dm:node-kind

Returns “text”.

dm:node-name

Returns the empty sequence.

dm:parent

Returns the value of the parent property.

dm:string-value

Returns the value of the content property.

dm:type-name

Returns xs:untypedAtomic.

dm:typed-value

Returns the value of the content property as an xs:untypedAtomic.

dm:unparsed-entity-public-id

Returns the empty sequence.

dm:unparsed-entity-system-id

Returns the empty sequence.

6.7.3 Construction from an Infoset

The character information items are required. A Text Node is constructed for each maximal sequence of character information items in document order.

The following infoset properties are required: [character code] and [parent].

The following infoset properties are optional: [element content whitespace].

A sequence of character information items is maximal if it satisfies the following constraints:

1. All of the information items in the sequence have the same parent.

2. The sequence consists of adjacent character information items uninterrupted by other types of information item.

3. No other such sequence exists that contains any of the same character information items and is longer.

Text Node properties are derived from the infoset as follows:

content

A string comprised of characters that correspond to the [character code] properties of each of the character information items.

If the resulting Text Node consists entirely of whitespace and the [element content whitespace] property of the character information items used to construct this node are true, the content of the Text Node is the zero-length string. Text Nodes are only allowed to be empty if they have no parents; an empty Text Node will be discarded when its parent is constructed, if it has a parent.

The content of the Text Node is not necessarily normalized as described in the [Character Model]. It is the responsibility of data producers to provide normalized text, and the responsibility of applications to make sure that operations do not de-normalize text.

parent

The node corresponding to the value of the [parent] property.

6.7.4 Construction from a PSVI

For Text Nodes constructed from the [schema normalized value] of elements, content contains the value of the [schema normalized value].

Otherwise, construction from a PSVI is the same as construction from the Infoset except for the content property. When constructing the content property, [element content whitespace] is not used to test if whitespace is collapsed. Instead, if the resulting Text Node consists entirely of whitespace and the character information items used to construct this node have a parent and that parent is an element and its {content type} is not “mixed”, then the content of the Text Node is the zero-length string.

Text Nodes are only allowed to be empty if they have no parents; an empty Text Node will be discarded when its parent is constructed, if it has a parent.

6.7.5 Infoset Mapping

A Text Node maps to a sequence of character information items.

Each character of the dm:string-value of the node is converted into a character information item as specified by this mapping:

[character code]

The Unicode code point value of the character.

[parent]

• If this node is the root of the infoset mapping operation, unknown.

• If this node has a parent, the information item that corresponds to the node returned by dm:parent.

• Otherwise no value.

[element content whitespace]

Unknown.

This sequence of characters constitutes the infoset mapping.